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Abstract. To prevent concurrency errors, programmers need to obey 
a locking discipline. Annotations that specify that discipline, such as 
Java’s SGuardedBy, are already widely used. Unfortunately, their semantics 
is expressed informally and is consequently ambiguous. This article high¬ 
lights such ambiguities and overcomes them by formalizing two possible 
semantics of aGuardedBy, using a reference operational semantics for a core 
calculus of a concurrent Java-like language. It also identifies when such 
annotations are actual guarantees against data races. Our work aids in 
understanding the annotations and supports the development of sound 
tools that verify or infer them. 


1 Introduction 

Concurrency can increase program performance by scheduling parallel indepen¬ 
dent tasks on multicore hardware, and can enable responsive user interfaces. 
However, concurrency might induce problems such as data races, i.e., concur¬ 
rent access to shared data by different threads, with consequent unpredictable 
or erroneous software behavior. Such errors are difficult to understand, diagnose, 
and reproduce. They are also difficult to prevent: testing tends to be incomplete 
due to nondeterministic scheduling choices made by the runtime, and model¬ 
checking scales poorly to real-world code. 

The simplest approach to prevent data races is to follow a locking discipline 
while accessing shared data: always hold a given lock when accessing a datum. 
It is easy to violate the locking discipline, so tools that verify adherence to the 
discipline are desirable. These tools require a specification language to express 
the intended locking discipline. The focus of this paper is on the formal definition 
of a specification language, its semantics, and the guarantees that it gives against 
data races. 

In Java, the most popular specification language for expressing a locking dis¬ 
cipline is the OGuardedBy annotation. Informally, if the programmer annotates a 
field or variable / as (SGuardedBy(if) then a thread may access / only while hold¬ 
ing the monitor corresponding to the guard expression E. The @GuardedBy anno¬ 
tation was proposed by Goetz [T2] as a documentation convention only, without 
tool support. The annotation has been adopted by practitioners; GitHub con¬ 
tains about 35,000 uses of the annotation in 7,000 files. Tool support now exists 
in Java PathFinder |18j . the Checker Framework HD], IntelliJ [22], and Julia [23] . 
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All of these tools rely on the previous informal definition of OGuardedBy (A) J6]. 
However, such an informal description is prone to many ambiguities. Suppose 
a field / is annotated as OGuardedBy (A), for some guard expression E. (1) The 
definition above does not clarify how an occurrence of the special variable this 
0 in E should be interpreted in client code; this actually depends on the context 
in which / is accessed. (2) It does not define what an access is. (3) It does not 
say whether the lock statement must use the guard expression E as written or 
whether a different expression that evaluates to the same value is permitted. (4) 

It does not indicate whether the lock that must be taken is E at the time of 
synchronization or E at the time of field access: side effects on E might make a 
difference here. (5) It does not clarify whether the lock on the guard E must be 
taken when accessing the field named f or the value bound to /. 

The latter ambiguity is particularly important. The interpretation of OGuardedBy 
based on names is adopted in most tools appearing in the literature [18122124) . 
whereas the interpretation based on values seems to be less common |10l24j . As 
a consequence, it is interesting to understand whether and how these two pos¬ 
sible interpretations of OGuardedBy actually protect against data races on the 
annotated field/variable. 

The main contribution of this article is the formalization of two different 
semantics for annotations of the form OGuardedBy (A) Type x: a name-protection 
semantics, in which accesses to the annotated name x need to be synchronized on 
the guard expression E , and a value-protection semantics, in which accesses to a 
value referenced by x need to be synchronized on E. The semantics clarify all the 
above ambiguities, so that programmers and tools know what those annotations 
mean and which guarantees they entail. We then show that both the name- 
protection and the value-protection semantics can protect against data races 
under proper restrictions on the variables occurring in the guard expression E. 
The name-protection semantics requires a further constraint — the protected 
variable or field must not be aliased. Our formalization relies on a reference 
semantics for a concurrent fragment of Java, which we provide in the structural 
operational semantics style of Plotkin [23j . 

We have used our formalization to extend the Julia static analyzer [M] to 
check and infer OGuardedBy annotations in arbitrary Java code. Julia allows the 
user to select either name-protection or value-protection. Our implementation 
reveals that most programmer-written OGuardedBy annotations do not satisfy 
either of the two alternative semantics given in this paper. For instance, in the 
code of Google Guava [13: (release 18), the programmer put 64 annotations on 
fields; 17 satisfy the semantics of name protection; 9 satisfy the semantics of value 
protection; the others do no satisfy any of the two. Fig. [T] shows an example of 
an annotation written by the programmers of Guava and that statisfy only the 
name protection. Namely, field runnables is annotated as OGuardedBy (this) but 
its value is accessed without synchronization at line 140 [13]. In this extended 
abstract proofs are omitted; they can be found in the appendix. 


Normally, this denotes the Java reference to the current object. 
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Fig. 1 Guava 18’s com.google, common.util, concurrent.ExecutionList class. 
The OGuardedBy annotation (line 66) is satisfied for name, but not for value, 
protection. 
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public final class ExecutionList { 

private QGuardedBy(this) RunnableExecutorPair runnables; 
public void execute() { 

RunnableExecutorPair list; 
synchronized (this) { 
list = runnables; 
runnables = null; 

> 

RunnableExecutorPair reversedList = null; 
while (list != null) { 

RunnableExecutorPair tmp = list; 
list = list.next; 
tmp.next = reversedList; 
reversedList = tmp; 

> 

> 

> 


Outline. Sec. [2] discusses the informal semantics of OGuardedBy by way of exam¬ 
ples. Sec. [3] defines the syntax and semantics of a concurrent fragment of Java. 
Sec.[4]gives formal definitions for both the name-protection and value-protection 
semantics. Sec. [5] shows which guarantees they provide against data races. Sec. ED 
describes the implementation in Julia. Sec. |7| discusses related work and con¬ 
cludes. 

2 Informal Semantics of OGuardedBy 

This section illustrates the use of OGuardedBy by example. Fig. [2] defines an ob¬ 
servable object that allows clients to concurrently register listeners. Registration 
must be synchronized to avoid data races: simultaneous modifications of the 
ArrayList might result in a corrupted list or lost registrations. Synchronization 
is needed in the getListenersO method as well, or otherwise the Java memory 
model does not guarantee the inter-thread visibility of the registrations. 

The interpretation of the OGuardedBy(this) annotation on field listeners 
requires resolving the ambiguities explained in Sec. [l] The intended locking dis¬ 
cipline is that every use of listeners should be enclosed within a construct 
synchronized ( container ) {...}, where container denotes the object whose field 
listeners is accessed (ambiguities (1) and (2)). For instance, the access original. listeners 
in the copy constructor is enclosed within synchronized (original) {...}. This 
contextualization of the guard expression , similar to viewpoint adaptation El, 
is not clarified in any informal definitions of OGuardedBy (ambiguity (3)). Further¬ 
more, it is not clear if a definite alias of original can be used as synchronization 
guard at line 5. It is not clear if original would be allowed to be reassigned 
between lines 5 and 6 (ambiguity (4)). Note that the copy constructor does not 
synchronize on this even though it accesses this. listeners. This is safe so long 
as the constructor does not leak this. This paper assumes that an escape analy- 
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Fig. 2 This code has a potential data race due to aliasing of the listeners field. 
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public class Observable { 

private @GuardedBy(this) List<Listener> listeners = new ArrayListoO ; 
public Observable() O 

public Observable(Observable original) { // copy constructor 
synchronized (original) { 

listeners.addAll(original.listeners); 

> 

> 

public void register(Listener listener) ■( 
synchronized (this) { 
listeners.add(listener); 

> 

> 

public List<Listener> getListenersO { 
synchronized (this) { 
return listeners; 

> 

> 

> 


sis [6] has established that constructors do not leak this. The @GuardedBy(this) 
annotation on field listeners suffers also from ambiguity (5): it is not obvious 
whether it intends to protect the name listeners (i.e., the name can be only used 
when the lock is held) or the value currently bound to listeners (i.e., that value 
can be only accessed when the lock is held). Another way of stating this is that 
OGuardedBy can be interpreted as a declaration annotation (a restriction on uses of 
a name) or as a type annotation (a restriction on values associated to that name). 

The code in Fig. [2] seems to satisfy the name-protection locking discipline 
expressed by the annotation OGuardedBy(this) for field listeners: every use of 
listeners occurs in a program point where the current thread locks its container, 
and we conclude that @GuardedBy(this) name-protects listeners. Nevertheless, 
a data race is possible, since two threads could call getListenersO and later 
access the returned value concurrently. This is inevitable when critical sections 
leak guarded data. More generally, name protection does not prevent data races 
if there are aliases of the guarded name (such as a returned value in our example) 
that can be used in an unprotected manner. The value-protection semantics of 
OGuardedBy is not affected by aliasing as it tracks accesses to the value referenced 
by the name, not the name itself. 

Any formal definition of @GuardedBy must result in mutual exclusion in order 
to ban data races. If x is @GuardedBy(F), then at every program point P where 
a thread accesses x (or its value), the thread must hold the lock on E. Mutual 
exclusion requires that two conditions are satisfied: (i) E can be evaluated at all 
program points P , and (ii) these evaluations always yield the same value. 

Point (i) is syntactic and related to the fact that E cannot refer to variables 
or fields that are not always in scope or visible at all program points P. This 
problem exists for both name protection and value protection, but is more sig¬ 
nificant for the latter, that is meant to protect values that flow in the program 
through arbitrary aliasing. For instance, the annotation OGuardedBy(listeners) 
cannot be used for value protection in Fig. [21 since the name listeners is not 
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Fig. 3 Value protection prevents data races; see itself in the guard expression. 
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public class Observable { 

private @GuardedBy(itself) List<Listener> listeners = new ArrayListoO ; 
public Observable() O 

public Observable(Observable original) { // copy constructor 
synchronized (original.listeners) { 
listeners.addAll(original.listeners); 

> 

> 

public void register(Listener listener) ■( 
synchronized (listeners) {. 
listeners.add(listener); 

> 

> 

public List<Listener> getListenersO { 
synchronized (listeners) { 
return listeners; 

> 

> 

> 


visible outside class Observable, but its value flows outside that class through 
method getListenersO and must be protected also if it accessed there. The 
value protection semantics supports a special variable itself in E, that refers 
to the current value of x being protected, without problems of scope or visibility. 
For instance, for value protection, the code in Fig. [2] could be rewritten as in 

Fig- El 

Point (ii) is semantical and related to the intent of providing a guarantee of 
mutual exclusion. For instance, in Fig. [3j value protection bans data races on 
listeners since the guard itself can be evaluated everywhere (point (i)) and al¬ 
ways yields the value of listeners itself (point (ii)). Here, the @GuardedBy(itself) 
annotation requires all accesses to the value of listeners to occur only when the 
current thread locks the same monitor — even outside class Observable, in a 
client that operates on the value returned by getListenersO. In Fig. |4l instead, 
field listeners is OGuardedBy (guard) according to both name protection and 
value protection, but the value of guard is distinct at different program points: 
no mutual exclusion guarantee exists and data races on listeners occur. 


3 A Core Calculus for Concurrent Java 

Some preliminary notions are needed to define our calculus. A partial function 
f from A to B is denoted by / : A B, and its domain is dom(/). We write 
f(v) f if v € dom(/) and f(v) t otherwise. The symbol <j> denotes the empty 
function, such that dom(</>) = 0; {iq i-> fi,..., v n i->- t n } denotes the function / 
with dom(/) = (vi,..., v n } and f(vi) = U for i = 1,..., n; f[vi h-» 

t n \ denotes the update of /, where dom(/) is enlarged for every i such that 
Vi £ dom(/). A tuple is denoted as (vq, ■ ■ ■ ,v n ). A poset is a structure ( A , <) 
where A is a set with a reflexive, transitive, and antisymmetric relation <. Given 
a £ A, we define f a = {a' : a < a'}. A chain is a totally ordered poset. 
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Fig. 4 If the guard expression refers to distinct values at distinct program points, 
concurrent accesses to listeners can race. 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 


public class Observable { 

private OGuardedBy(guard) List<Listener> listeners = new ArrayList<>(); 
private Object guardl = new ObjectO; 
private Object guard2 = new ObjectO; 
public Observable() O 

public Observable(Observable original) { // copy constructor 
Object guard = guardl; 
synchronized (guard) { 

listeners.addAll(original.listeners); 

> 

> 

public void register(Listener listener) { 

Object guard = guard2; 
synchronized (guard) { 
listeners.add(listener); 

> 

> 

> 


3.1 Syntax 

Symbols f,g,x,y, ... range over a set of variables Var that includes this. Vari¬ 
ables identify either local variables in methods or instance variables ( fields ) of 
objects. Symbols m,p, ... range over a set MethodName of method names. There 
is a set Loc of memory locations, ranged over by l. Symbols k, kq, k\, ... range 
over a set of classes (or types ) Class, ordered by a subclass relation <; (Class, <) 
is a poset such that for all k £ Class the set "f/c is a finite chain. Intuitively, 
K\ < k ,2 means that K\ is a subclass (or subtype ) of « 2 - If u? £ MethodName, 
then K.m denotes the implementation of m inside class k, if any. The partial 
function lookup () : Class x MethodName Class formalizes Java’s dynamic 
method lookup, i.e. the runtime process of determining the class containing the 
implementation of a method on the basis of the class of the receiver object: 
lookup(K,m ) = min( f K.m) if t K.m 7^ 0 and is undefined otherwise, where 
t K.m = {k' € t k | m is implemented in k'} is a finite chain since f K.m C f k. 

The set of expressions Exp, ranged over by E, and the set of commands Com, 
ranged over by C, are defined as follows. Method bodies, ranged over by B, are 
skip-terminated commands. 


E 

::= x 

E.f K(f 1 =E 1 ,...,f n 

= E n ) 


C 

::= decl x = E x := E x.f : 

= E | C\C 

skip | E.m ( ) 

B 

spawn 

::= skip 

E.m () | synGCTh-CC} 

C; skip 

monitor_enter (/) 

| monitor _exit (2) 


Constructs of our language are simplified versions of those of Java. For instance, 
loops must be implemented through recursion. We assume that the compiler 
ensures some standard syntactical properties, such as the same variable cannot 
be declared twice in a method, and the only free variable in a method’s body is 
this. These simplifying assumptions can be relaxed without affecting our results. 
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Fig. 5 Running example. 
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public class K { 

private K1 x = new Kl(); 
private K2 y = new K2(); 
public void m() { 

K1 z = x; 

K2 w = new ObjectO; 
synchronized (z) { 
y = z.f; 


by-name 

by-value 


w = y; 

1 

w.g = new ObjectO; 

> 

> 

field x 
field y 
variable z 
variable w 

OGuardedBy(this.x) 
@GuardedBy(itself) 

OGuardedBy(itself) 

OGuardedBy(itself) 


class K1 { 

K2 f = new K2(); 

> 




class K2 { 

Object g = new ObjectO; 

} 





Expressions are variables, field accesses, and a construct for object creation, 
k(/i = E-[., f n = E n ), that creates an object of class k and initializes each 
held ft to the value of Ei. Command decl declares a local variable. The dec¬ 
laration of a local variable in the body B of a method to must introduce a 
fresh variable never declared before in B , whose lifespan starts from there and 
reaches the end of B. The commands for variable/field assignment, sequential 
composition, and termination are standard. Method call E.m{ ) looks up and 
runs method m on the runtime value of E. Command spawn E.m( ) does the 
same asynchronously, on a new thread. Command sync (.E ) {C} is like Java’s 
synchronized: the command C can be executed only when the current thread 
holds the lock on the value of E. monitor_enter (Z) and monitor_exit(Z) cannot be 
used by the programmer: our semantics introduces them in order to implement 
object synchronization. 

The set of classes is Class = {k : MethodNames —*• B | dom(ft) is finite}. 
The binding of fields to their defining class is not relevant in our formalization. 
Given a class n and a method name to, if n(in) = B then n implements to with 
body B. For simplicity, this is the only free variable in B and methods have no 
formal parameters and/or return value. A program is a finite set of classes and 
includes a distinguished class Main that only defines a method main where the 
program starts: Main = {main B ma i n }. 

Example 1. Fig. [5] gives our running example in Java. In our core language, 
the body of method m is translated as follows: B m = decl z = this.x; decl w 
= 0bject(); sync(z) { this.y := z.f; w := this.y }; w.g := 0bject(); skip, 
with classes K = {m I —> B m }, K1 = </>, K2 = </>, and Object = (f>. 

3.2 Semantic Domains 

A running program consists of a pool of threads that share a memory. Initially, 
a single thread runs the main method. The spawn E.m{ ) command adds a new 












thread to the existing ones. Each thread has an activation stack S and a set C of 
locations that it currently locks. The activation stack S' is a stack of activation 
records R of methods. Each R consists of the identifier n.m of the method, the 
command C to be executed when R will be on top of the stack ( continuation ), 
and the environment or binding a that provides values to the variables in scope in 
R. For simplicity, we only have classes and no primitive types, so the only possible 
values are locations. Formally, Env = {a : Var Loc | dom(tr) is finite}. 

Definition 1. Activation records, ranged over by R, activation stacks, ranged 
over by S, and thread pools, ranged over by T, are defined as follows: 

R ::= K.m[C] a (activation record for n.m) 

S ::= e | R :: S (activation stack, possibly empty) 

T ::= [S’]/! | T || T (thread pool). 

The number of threads in T is written as f(T. 

An object o is a triple containing the object’s class, an environment binding 
its fields to their corresponding values, and a lock, i.e., an integer counter incre¬ 
mented whenever a thread locks the object (locks are re-entrant). A memory /i 
maps a finite set of already allocated memory locations into objects. 

Definition 2. Objects and memories are defined as Object = Class x Env x N 
and Memory = {/i : Loc —*■ Object | dom(/z) is finite}, with selectors classip) = 
k, env{o) = a and lock#(o) = n, for every o = (k, <t, n) G Object. We also 
define o[f n- l] = (k, a[f l\,n) and lock + (o) = (k , a, n+1) and lock~{o) = 
(k , a, max(0, n—1)). 

For simplicity, we do not model delayed publication of field updates, allowed in 
the Java memory model, as that is not relevant for our semantics and results. 
Our goal is to identify expressions definitely locked at selected program points 
and locking operations are immediately published in the Java memory model. 
Hence, our memory model is a deterministic map shared by all threads. 

The evaluation of an expression E in an environment a and in a memory /i, 
written yields a pair {l,p'), where l is a location (the runtime value of E) 

and p! is the memory resulting after the evaluation of E. Given a pair (l,p) we 
use selectors loc((l,p)) = l and mem((l,p)) = p. 

Definition 3 (Evaluation of Expressions). The evaluation function has the 
tyP e [ 1 : ( Exp x Env x Memory ) —*■ ( Loc x Memory) and is defined as: 

= f M®), fj) {E.fTa = f (env(p'(l))(f), p), where [E]^ =(l, p') 

[K(/i=Ei,..,/„=E n )]0 = f (l, p n [l h> (k, a', 0)]), where 

(1) p 0 = p and (k, pi) = \EiYJ~ 1 , for i G [l..n] 

(2) l is fresh in p n , that is p n {l ) f 

(3) a' G Env is such that crffi) = U for i G [l..n], while cr'(y)f elsewhere. 

We assume that [ ] is undefined if any of the function applications is undefined. 

In the evaluation of the object creation expression, a fresh location l is allocated 
and bound to an unlocked object whose environment a' binds its fields to the 
values of the corresponding initialization expressions. 
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Table 1 Structural operational semantics for sequential commands. 


[decl] 


l E Ta = ( z > AO cOOf <*' = a\x i-t 1} 

(|"ft.m[deci x = E] a ~\C, p) —(r«.m[skip] CT /l£, p) 

l E Y = ( l > d) o' d =M o\x h-> Z] 

- [var-assj 

(| ~n.m[x := iJ] CT ]-C, p) —>■ (|"K.m[ski P ] CT /]£, p) 

l E ia = ( l > m') o = At(o-(a;)) o' ^ o[f t-> Z] p” ^ p'[ojx) ^ o'] 
(| ~K.m[x.f := E]a.~\C, p) -U (|‘K.m[ski P ] CT ]£, p") 


[field-ass] 


<rM) — > (ric.m[C(] g >l£ , l //) Ci ^ £.p() Ci # spawn E.pQ 

(\K.m[Ci; C 2 ]ct 1T, /r) -U (|'k.to[C'[; C 2 ] CT '1>C', //) 


[seq] 


--- [seq-skip] 

(["K.m[skip; C] CT ]£, p) —> (["K.m[C] CT ]£, p) 

pS]£ = (Z, p') k' = lookup {clas s [p' (l)),p) k'( p) = B 
- [invoc] 

(| ~K.m[E.p( )\C]a :: S~\C, p) -U- {r«'-P[-B]{this^q :: K.m[C] a :: S~\£, p') 


3.3 Structural Operational Semantics 

Our operational semantics is given in terms of a reduction relation on configura¬ 
tions of the form (T, p), where T is a pool of threads and p is a memory that 
models the heap of the system. We write (T, p) (T r , p') for representing an 
execution step in which n > 1 denotes the position of the thread in T that fires 
the transition, starting from the leftmost in the pool T (thread 1). We write —> 
instead of to abstract on the running thread; —>* denotes the reflexive and 
transitive closure of —We first introduce reduction rules where the activation 
stack consists of a single activation record, then lift to the general case. 

Table [l] deals with sequential commands. In rule [decl] an undefined variable x 
is declared. Rules [var-ass] and [field-ass] formalize variable and field assignment, 
respectively. Rule [seq] assumes that the first command is not of the form E.p( ) 
or spawn E.p( ); these two cases are treated separately. In rule [invoc] the receiver 
E is evaluated and the method implementation is looked up from the dynamic 
class of the receiver. The body of the method is put on top of the activation stack 
and is executed from an initial state where only variable this is in scope, bound 
to the receiver. Unlike previous rules, this rule deals with the whole activation 
stack rather than assuming only a single activation record. 

Table [2] focuses on concurrency and synchronization. The spawn of a new 
method is similar to a method call, but the method body runs in its own new 
thread with an initially empty set of locked locations. In rule [sync] the location 
l associated to the guard E is computed; the computation can proceed only if a 











10 


Table 2 Structural operational semantics for concurrency and synchronization. 


= (l, p') k' = lookup (class (p (l)),p) k! (p) = B 
(|'K.m[spawn E.p( ); C] CT :: S]£, —->■ :: el0 || \K.m[C] a :: Sj£, p') 

IEZ = (1^’) 


[spawn] 


( \K,.TYl[sync(.E){.C}]<j-\jCi fl) - 1 ( |~K.77l[monitor_enter (/); C\ monitor.exit (Z)]cr~| jC, fl') 

lock#(p(l)) = 0 £'^£u{/} p! d dp[l lock+ (p(l))} 


[sync] 


(]~/‘C.m[monitor_enter (/)]<j~] £, p') - y ( [T .TTl [skip] CT "j Cf, p !) 

l£C p ,d Mp[l^y lock + (p(l))} 


[acquir e-lock] 


(]"ft;.?n]monitor_enter (/)]o-] £, p) - y ( ["K.TTifskip]^"] £, p') 

lock# (p(l)) >1 p' = p[l (->• lock~ (p(l))] 
(]"AC.7n]monitor_exit(b]o-]£, p) -^ ( ]"K.m]skip] CT ] £, p') 

lock#{p{l)) = 1 C d MC\ {Z} p d Jp[l lock~(p(l))\ 

([~K.?7l[monitor_exit (b]o-~] £, p) -> { [~K.m.[skip]^] CJ , /£} 


[reentrant-lock] 


[decrease-lock] 


[release-lock] 


Table 3 Structural operational semantics: structural rules. 


<rz?iA p) -4 (\R’]c r , p') 


[push] 


(\Rr.S\C, p) A (rzz'::51£', p') (]"/t.m[skip]o-::S]£, p) -4> ([S]£, p) 

{Tu p) ^4 (t[, p') . (T2, p) ^4 (73, 4) 


[pop] 


(Ti [| T a , /*> —> (T[ || T a , p') 

- 1 - [end-1] 

(\e]C || T, p) A (T, p) 


[par-1] 


<Ti || Ta, p) #Tl+n > (Tr || 73, //} 

- [end-rl 

<T || \e]C, p) (T , 


[par-r] 


lock action is possible on l. The lock will be released only at the end of the critical 
section C. Rule [acquire-lock] models the entering of the monitor of an unlocked 
object. Rule [reentrant-lock] models Java’s lock reentrancy. Rule [decrease-lock] 
decreases the lock counter of an object that still remains locked, as it was locked 
more than once. When the lock counter reaches 0, rule [release-lock] can fire to 
release the lock of the object. 

In Table [3] rule [push] lifts the execution of an activation record to that of a 
stack of activation records. The remaining structural rules are straightforward. 

Definition 4 (Operational Semantics of a Program). The initial config¬ 
uration of a program is (To, po) where To = [Mam.mam[B TOa j„]/t/ l i SM .; init r]0 
and po = {linn !->• (Main, </>, 0)}. The operational semantics of a program is the 
set of traces of the form (To, po) —>* (T, p). 
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Example 2 . The implementation in Ex. [lj becomes a program by defining B ma i n 
as: k(x = Ki(f = K2(g = object())), y = K2(g = object(})).m(); skip. The operational se¬ 
mantics builds the following maximal trace from (To, pfi) that, for convenience, 
we divide in eight macro-steps: 

1 . —7 (["K.m[decl z = this.x; . . .] CT1 :: Main. 771 Clin [skip] }] 0 , pi) 

with p i = po [Z 1 —7 o, l\ i —7 Oi, I2 1 —^ 02 , 1 3 1 —7 03 ,Z4 1 —7 04, 1 5 i—^ 04] 5 
o d M (k, {x i-i Zi,y !-)■ Z2}, 0 ); 01 (ki, {f i-i l 3 }, 0 ); 02 (k 2, (g >->■ Z 4 }, 0 ); 

03 = (k 2, {g t —7 Z5}, 0 ); 04 = (object, <j), 0 ); (Ji = {this t—>■ 1 } 

2 . —7 ( ["K.m[decl w = Object (}; . . .] CT2 :: ...] 0 , p 1} with 02 == 01 [z 1—Zi ] 

3 . — 7 * ([K.m[sync(z){. .] CT3 :: . . .] 0 , P2) with fj,2 = pi\J .6 <—7 04]; a 3 = C2[w I 7 l&] 

4 . —7 (["K.m[this.y z.f; . . . ; monitor_exit (Zi); . . .]<T3 :: • • -]{Zl}, P3) 

with p3 p,2 [Zi lock + (oi)] 

5 . —7 ( [~K.m[w := this.y; monitor.exit (Zi );...] 0-3 ::...] {Zi }, pf) 

with p 4 P3 [Z i->- 0']; o' 'M (k, {x 1—>■ Zi, y 1—>• Z 3 }, 0 ) 

6. —>* ( (K.m[monitor_exit C/i) ; w.g := Object() ; skip] CT4 :: . . .] {Zi}, pf) with 04 = <73 [w 1—>■ Z3] 

7 . —>* (|"K.m[w.g := Object(}; skip]o- 4 :: . . .] 0 , ^5} with P5 = /i 4 [Zi Oi] 

8. ->* (( Main, main [skip] {t h is^->i init }10, Pe) with p 6 = ^5^5 >->• o 4 ]. 

Our semantics lets us formalize some properties on the soundness of the lock¬ 
ing mechanism, that we report in Appendix[B] Here we just report a key property 
used in our proofs, that states that two threads never lock the same location (i.e., 
object) at the same time. It is proved by induction on the length of the trace. 

Proposition 1. Let (To, po) — 7 * ([«Si]£i || ... || \Sn\C n , p) be an arbitrary 
trace. For any i,j £ ( 1 ... n} ; i j entails An Cj = 0 . 

4 Two Semantics for OGuardedBy Annotations 

This section gives two distinct formalizations for locking specifications of the 
form OGuardedBy (T) Type x, where E is any expression allowed by the language, 
possibly using a special variable itself that stands for the protected entity. 

4.1 Name-Protection Semantics 

In a name-protection interpretation, a thread must hold the lock on the value 
of the guard expression whenever it accesses (reads or writes) the name of the 
guarded variable/fielcl. Def. [ 5 ] formalizes the notion of accessing an expression 
when a given command is executed. For our purposes, it is enough to consider a 
single execution step; thus the accesses in C\\ C2 are only those in C\. When an 
object is created, only its creating thread can access it. Thus field initialization 
cannot originate data races and is not considered as an access. The access refers 
to the value of the expression, not to its lock counter, hence sync(T){C> does 
not access E. For accesses to a held /, Def. O keeps the exact expression used for 
the container of /, that will be used in Def. [ 7 ] for the contextualization of this. 

Definition 5 (Expressions Accessed in a Single Reduction Step). The 

set of expressions accessed in a single execution step is defined as follows: 
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acc(x) = {a-} acc (E.f) = acc (E) U {E.f} 

acc(K(/i=£’i,..., f n =E n )) d 4 U”=i acc(Ei) 


acc(x := E) = acc(a:) U acc(T) 
acc(x.f := E) M acc (x.f) U acc(E) 
acc(spawn E.m( )) = acc (E) 
acc(monitor_exit (Z)) =0 

acc(sync(x){C}) = 0 = acc(skip) 
acc(sync (k(/i =E 1 ,...,f n = E n ))iC }) =' acc(«(/i=£’i,..., f n =E n )). 

We say that a command C accesses a variable x if and only if x £ acc(C); we 
say that C accesses a /ie/d / */ and only if E.f £ acc(C'), /or some expression 
E. 


acc(ded x = E) = acc (E) 
acc(Ci; C 2 ) = acc (Ci) 
acc (E.m ()) = acc(T) 
acc(monitor_enter(Z)) = 0 
acc(sync(C./){C}) = acc(C) 


We now define OGuardedBy for local variables (Def. [G]) and for fields (Def. [3). 
In Sec. 0 we have already discussed the reasons for using the special variable 
itself in the guard expressions when working with a value-protection semantics. 
In the name-protection semantics, itself denotes just an alias of the accessed 
name: OGuardedBy (itself ) Type x is the same as OGuardedBy (x) Type x. 

Definition 6 (OGuardedBy for Local Variables). A local variable x of a method 
K.m in a program is name protected by OGuardedBy (I?) if and only if for every 
derivation (To, po) —>* (T, p) ■ ■ ■ in which the n-th thread in T is 

\n.m[C] cT :: 5]£, whenever C accesses x we have loc £ C. 

Example 3. In Ex. [2) variable z of K.m is name protected by OGuardedBy (this .x) 
since the name z is accessed at the macro-step 5 only, where [[this. x]^[ ltselfl _ >ii ] = 
(h, P 3 )', during those reductions, the current thread holds the lock on the object 
bound to l\. According to Def. [5l macro-steps 2 and 3 do not contain accesses 
since they are declarations; macro-step 4 does not access z since it is a synchro¬ 
nization. 

Definition 7 (OGuardedBy for Fields). A field f in a program is name pro¬ 
tected by OGuardedBy (.E) if and only if for every trace (To, pf) —>* (T, p) —-> 
...in which the n-th thread in T is \n.m[C] c , :: 5]£, whenever C accesses f, 
i.e. E'.f £ acc(C), for some E', with \E '= (/', p') and l" = env(p'(l'))f, we 

have loc ([£C [thls ^ iitself ^ r] ) G C. 

Notice that the guard expression E is evaluated in a memory p' obtained by the 
evaluation of the container of /, that is E\ and in an environment where the 
special variable this is bound to V , i.e. the evaluation of the container of /. 

Remark 1. Def. ED and [7] evaluate the guard E at those program points where 
x is accessed, in order to verify that its lock is held by the current thread. 
Hence E can only refer to itself and variables in scope at those points, and 
for its evaluation we must use the current environment a. A similar observation 
holds for the corresponding definitions for the value-protection semantics in next 
section. 


13 


Example 4 - In Ex. [21 field y is name protected by OGuardedBy(this.x). It is 
accessed at macro-step 5, where [this.i]^[ thlah+liltBamii ] = (h, p 3 ), and at 
macro-step 6, where [this.x]^j thlB1 _ >Jjltaelfl _ >Ji ] = (h, /x 4 ). In both cases, the 
active and only thread holds the lock on the object bound to l\. 

4.2 Value-Protection Semantics 

An alternative semantics for OGuardedBy protects the values held in variables or 
fields rather than their name. In this value-protection semantics, a variable x is 
OGuardedBy (E) if wherever a thread dereferences a location l eventually bound 
to x, it holds the lock on the object obtained by evaluating E at that point. In 
object-oriented parlance, dereferencing a location l means accessing the object 
stored at l in order to read or write a field. In Java, accesses to the lock counter 
are synchronized at a low level and the class tag is immutable, hence their 
accesses cannot give rise to data races and are not relevant here. Dereferences 
(Def. [HI are very different from accesses (Def. [5]). For instance, statement v.f 
:= w.g.h accesses expressions v, v.f, w, w.g and w.g.h but dereferences only the 
locations held in v, w and w. g: locations bound to v. f and w.g.h are left untouched. 
Def. [8] formalizes the set of locations dereferenced by an expression or command 
to access some field and keeps track of the fact that the access is for reading (—>•) 
or writing (<— ) the field. Hence dereference tokens are l.f<— or l.f —>•, where l is 
a location and / is the name of the field that is accessed in the object held in l. 

Definition 8 (Dereferenced Locations). Given a memory p and an envi¬ 
ronment a, the dereferences in a single reduction are defined as follows: 
deref (s)£ U 0 deref(.E./)£ {loc {\E\^) ./->} U deref (E)£ 

deref(«(/i = E 1 ,...,f n = E n ))£ ilijiU deref(.E))£ 
deref(decl x = E)£ = deref(£1)^ deref(cc := E)% = deref(£?)£ 
deref(sync (E){Cy)£ = deref (E)£ deref(Ci; =deref(Ci)^ 
deref (monitor .enter (D )£ ^0 deref (a:./ := E)£ = (cr(x)./^—}U deref (E)£ 

deref (monitor.exit (/) = 0 deref (skip)J) = 0 

deref(£l.m())^ = deref(spawn E.m( ))£ = deref(T)^ . 

Its projection on locations is dereflociC)fl = {I \ there is f such that l.f E 
deref(C l )(( or l.f—* G deref(C')')}. 

Def. [HI fixes an arbitrary execution trace t and collects the set C of locations 
that have ever been bound to x in t. Then, it requires that whenever a thread 
dereferences one of those locations, that thread must hold the lock on the object 
obtained by evaluating the guard E. 

Definition 9 (OGuardedBy for Local Variables). A local variable x of a method 
n.m in a program is value-protected by OGuardedBy (.E) if and only if for any 
derivation (To, po) — ^ • • • — I—(T), pf) —letting 

- T" = [A;”. to" [(?”]<,» :: be the n-th thread of the pool Tj, for j > 0 

— C = Uj>o{ (T j 3 ( a; ) I k ™ 3 .m ™ 3 =n.m and a ™ 1 (x) ),} be the set of locations 
eventually associated to variable x 
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— Xi = derefloc(C^' t ) l \ i n C be those locations in C dereferenced at step — 

Then, for every l £ Xi it follows that loc £ £"‘. 

Note that £ contains all locations eventually bound to x, also in the past, not 
just those bound to x in the last configuration (T), m). This is because the value 
of x might change during the execution of the program and flow through aliasing 
into other variables, that later get dereferenced. 

Example 5 . In Ex. [2] variable z is value-protected by @GuardedBy (itself) . The 
set X for z of Def. [9] is {£}. Location l\ is only dereferenced at macro-step 5 , 
where the corresponding object o\ is accessed to obtain the value of its field /. 
At that program point, location l-\ is locked by the current thread. 

Definition 10 (@GuardedBy for Fields). A field f in a program is value-protected 
by SGuardedBy (T) if and only if for any derivation (To, pfi) ”° ■ > 

(Tj, pf} —‘‘—t • • ■ , letting 

- T" = | 'kj.rrij[Cj , ] (T n :: be the n-th thread of the pool Tj, for j > 0 

- c = u J>0 { env(p,j(l))(f) | l£dom(pj) and env(pj(l))(f) j.} be the set of 
locations eventually associated to field f 

— Xi = derefloc(C™') l pi i n C be those locations in C dereferenced at step — 

Then, for every l £ Xi it follows that loc ^[S]^n i |. ltself| _ > ^^ £ £"*. 

Example 6 . In Ex. [2] field x is value-protected by SGuardedBy (itself) . The set 
X for x of Def. [TO] is {Zi} and we conclude as in Ex. [5] 

Remark 2 . The two semantics for OGuardedBy are incomparable: neither entails 
the other. For instance, in Ex.[2]field x is value protected by OGuardedBy (itself), 
but is not name protected: x is accessed at macro-step 1. Field y is name pro¬ 
tected by OGuardedBy (this, x) but not value protected: its value is accessed at 
macro-step 8 via w. In some cases the two semantics do coincide. Variable z 
is OGuardedBy(itself ) in both semantics: its name and value are only accessed 
at macro-step 5 , where they are locked. Variable w is not OGuardedBy (itself ) 
according to any semantics: its name and value are accessed at macro-step 8. 

5 Protection against Data Races 

In this section we provide sufficient conditions that ban data races when OGuardedBy 
annotations are satisfied, in either of the two versions of Sec. 14.11 and 14.21 First, 
we formalize the notion of data race. Informally, a data race occurs when two 
threads a and b dereference the same location l, at the same time, to access a 
field of the object stored at l and at least one of them, say a, modifies the field. 
We formalize below this definition for our language. 
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Definition 11 (Data race). Let (To, /to) —1* (T, p), whereTi = \ki.m t [C-i] ai :: 
Si~\Ci is the i-th thread ofT. A data race occurs at a location l at (T, p) during 

the access to afield f if there are a/b such that (T, p) (T 1 , / 1 !), (T, p) 

(T", [A'), l.f<r- G deref(C 0 )^ a and (l.f<- G deref(C{,)£ 6 or l.f-> G deref(C' b )^J. 

In Sec. [2] we said that accesses to variables (and fields) that are OGuardedBy (.E) 
occur in mutual exclusion if the guard E is such that it can be evaluated at 
distinct program points and its evaluation always yields the same value. This 
means that E cannot contain local variables as they cannot be evaluated at 
distinct program points. Thus, we restrict the variables that can be used in 
E. In particular, itself can always be used since it refers to the location being 
dereferenced. For the name-protection semantics for fields, this can also be used, 
since it refers to the container of the guarded field, as long as it can be uniquely 
determined; for instance, if there is no aliasing. Indeed, Sec. [2] shows that name 
protection without aliasing restrictions does not ban data races, since it protects 
the name but not its value, that can be freely aliased and accessed through other 
names, without synchronization. In a real programming language, aliasing arises 
from assignments, returned values, and parameter passing. Our simple language 
has no returned values and only the implicit parameter this. 

Definition 12 (Non-aliased variables and fields). Let P be a program and 
x a variable or field name. We say that a name x is non-aliased in P if and only 
if for every arbitrary trace (To, /.to) —V (T, p) of P, where Ti = \ki.mi[Ci\ ai 
Sf\Ci is the i-th thread of T, we have 

— whenever Oj(x) = l, for some j and l: 

• there is no y, y / x, such that (Jj(y) = l 

• there is no k, k / j, such that <Jk(y) = h for some y 

• there is no l 1 such that env(p(l'))(y) = l, for some y 

— whenever env(p(l’))(x) = l, for some l' and l: 

• there are no y and j such that <jj (y) = l 

• there are no y and l", V l", such that env(p(l"))(y) = l. 

Checking if a name is non-aliased can be mechanized [3] and prevented by syntac¬ 
tic restrictions. Now, everything is in place to prove that, for non-aliased names, 
the name-protection semantics of OGuardedBy protects against data races. 

Theorem 1 (Name-protection semantics vs. data race protection). Let 

E be an expression in a program, and x be a non-aliased variable or field that is 
name protected by OGuardedBy ( E). If x is a variable, let E contain no variable 
distinct from itself; if x is afield, let E contain no variable distinct from itself 
and this. Then, no data race can occur at those locations bound to x, at any 
execution trace of that program. 

The absence of aliasing is not necessary for the value-protection semantics. 

Theorem 2 (Value-protection semantics vs. data race protection). Let 

E be an expression in a program, and x be a variable/field that is value-protected 
by OGuardedBy (E). Let E have no variable distinct from itself. Then no data 
race can occur at those locations bound to x, during any execution of the program. 
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Both results are proved by contradiction, by supposing that a data race occurs 
and showing that two threads would lock the same location, against Prop.Q] 

6 Implementation in Julia 

The Julia static analyzer infers OGuardedBy annotations. The user selects the 
name-protection or the value-protection semantics. As discussed in Sec. [2] and 
then formalized in Sec. 01 a OGuardedBy (P) annotation holds for a variable or 
field x if, at all program points P where x is accessed (for name protection) or 
one of its locations is dereferenced (for value protection), the value of E is locked 
by the current thread. The inference algorithm of Julia builds on two phases: (i) 
compute P; (ii) find expressions E locked at all program points in P. 

Point (i) is obvious for name protection, since accesses to x are syntactically 
apparent in the program. For value protection, the set P is instead undecidable, 
since there might be infinitely many objects potentially bound to x at runtime, 
that flow through aliasing. Hence Julia overapproximates P by abstracting ob¬ 
jects into their creation point in the program: if two objects have distinct creation 
points, they must be distinct. The number of creation points is finite, hence the 
approximation is finitely computable. Julia implements creation points analysis 
as a concretization of the class analysis in [21] , where objects are abstracted in 
their creation points instead of just their class tag. 

Point (ii) uses the definite aliasing analysis of Julia, described in [IT. At each 
synchronized (G) statement, that analysis provides a set L of expressions that are 
definitely an alias of G at that statement (i.e., their values coincide there, always). 
Julia concludes that the expressions in L are locked by the current thread after 
the synchronized (G) and until the end of its scope. Potential side-effects might 
however invalidate that conclusion, possibly due to concurrent threads. Hence, 
Julia only allows in L fields that are never modified after being defined, which can 
be inferred syntactically for a field. For name protection, viewpoint adaptation 
of this is performed on such expressions (Def. [TJ) . These sets L are propagated 
in the program until they reach the points in P. The expressions E in point (ii) 
are hence those that belong to L at all program points in P. 

Since OGuardedBy (P) annotations are expected to be used by client code, E 
should be visible to the client. For instance, Julia discards expressions E that 
refer to a private field or to a local variable that is not a parameter, since these 
would not be visible nor useful to a client. 

The supporting creation points and definite aliasing analyses are sound, hence 
Julia soundly infers OGuardedBy (P) annotations that satisfy the formal definitions 
in Sec. 0] Such inferred annotations protect against data races if the sufficient 
conditions in Sec. [5] hold for them. 

More detail and experiments with this implementation can be found in [?]. 

7 Conclusions, Future and Related Work 

We have formalized two possible semantics for Java’s OGuardedBy annotations. 
Coming back to the ambiguities sketched in Sec. [H we have clarified that: (1) this 
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in the guard expression must be interpreted as the container of the guarded field 
and consistently contextualized (Def. 0. (2) An access is a variable/field use for 
name protection (Def. 0 0 and0. A value access is a dereference (field get/set 
or method call) for value protection; copying a value is not an access in this case 
(Def. mini and [Toll. (3) The value of the guard expression must be locked when a 
name or value is accessed, regardless of how it is accessed for locking (Def. 000 
and [Toll . (4) The lock is taken on the value of the guard expression as evaluated 
at the access to the guarded variable or field (Def. 000 anclfTOland rule [sync]). 
(5) Either the name or the value of a variable can be guarded, but this choice 
leads to very different semantics. Namely, in the name-protection semantics, the 
lock must be held whenever the variable/field’s name is accessed (Def. 0 0 
and 0. In the value-protection semantics, the lock must be held whenever the 
variable/field’s value is accessed (Def. 00 and [Toll. regardless of what expression 
is used to access the value. Both semantics yield a guarantee against data races, 
though name protection requires an aliasing restriction (Th. 0and0. 

This work could be extended by enlarging the set of guard expressions that 
protect against data races. In particular, we have found that programmers often 
use this in guard expressions, but in that case we have a proof of protection only 
for the name-protection semantics at the moment. Our simple language already 
admits local variables and global variables (in object-oriented languages, these 
are the fields of the objects). It could be further extended with static fields. We 
believe that the protection results in Sec. 0 still hold for them. Another aspect 
to investigate is the scope of the protection against data races. In this article, a 
single location is protected (Def. [Til) , not the whole tree of objects reachable from 
it: our protection is shallow rather than deep. Deep protection is possibly more 
interesting to the programmer, since it relates to a data structure as a whole, 
but it requires to reason about boundaries and encapsulation of data structures. 

There are many other formalizations of the syntax and semantics of concur¬ 
rent Java, such as |l|8j . There is a formalization that also includes extensions 
to Java such as RMI [2j. Our goal here is the semantics of annotations such as 
OGuardedBy. Hence we kept the semantics of the language to the minimum core 
needed for the formalization of those program annotations. Another well-known 
formalization is Featherweight Java fl5] . a functional language that provides a 
formal kernel of sequential Java. It does not include threads, nor assignment. 
Thus, it is not adequate to formalize data races, which need concurrency and 
assignments. Middleweight Java 0 is a richer language, with states, assignments 
and object identity. It is purely sequential, with no threads, and its formalization 
is otherwise at a level of detail that is unnecessarily complex for the present work. 
Welterweight Java [20] is a formalization of a kernel of Java that includes assign¬ 
ments to mutable data and threads. Our formalization is similar to theirs, but it 
is simpler since we do not model aspects that are not relevant to the definition 
of data races, such as subtyping. The need of a formal specification for reasoning 
about Java’s concurrency and for building verification tools is recognized Mill 
but we are not aware of any formalization of the semantics of Java’s concurrency 
annotations. Our formalization will support tools based on mo del-checking such 
as Java PathFinder [TS] and Bandera mm , on type-checking such as the Checker 
Framework [10] , or on abstract interpretation such as Julia |24j . Finally, our com- 
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panion paper [?] presents the details of the implementation of the Julia analyzer 
and of a type-checker for SGuardedBy annotations, together with extended exper¬ 
iments that show how these tools scale to large real software and provide useful 
results for programmers. 
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A Proofs of Sec [5] 

Theorem 3 (Name-protection semantics vs. data race protection). Let 

E be an expression in a program, and x be a non-aliased variable or field that is 
name protected by OGuardedByCi?) . If x is a variable, let E contain no variable 
distinct from itself; if x is a field, let E contain no variable distinct from itself 
and this. Then, no data race can occur at those locations bound to x, at any 
execution trace of that program. 

Proof. The proof is by contradiction. Let (T 0 , p 0 ) —»•* (T, p) be an arbitrary 
trace of our program, where T) = |7cj.m.j[C'j] cri :: S.f C, is the f-th thread of T. 
By Def. [TTJ if a data race occurred in (T, p), at some location l, bound to x, 
then (T, p) could evolve in at least two ways, say 

(T, p) A {T, p>) and (T, p) A (T", p") 

that dereference l in two different threads a and b. As x is non-aliased, by 
Def. [T2] it cannot be used in one thread as a variable and in the other as a 
field. As a ^ b, by Def. [T2] the name x cannot be used in both threads as local 
variable bound to the same location l. Thus, there is only one possibility: x is 
a field accessed by both threads, a and b, to dereference the location l. This 
means that there exist two expressions E a and Eb such that E a .x £ acc (C a ) 
and Eb-X £ acc(Cb). As x is non-aliased, by Def. IT/l there cannot be two dif¬ 
ferent containers (objects) of the same field x. As a consequence, the two ex¬ 
pressions E a and Eb must evaluate to the same value, i.e. [£? a ]^ = = 

(l', p'), for some l' and p!. We recall that C a and Cb denote the set of loca¬ 
tions locked in ( T, p) by thread a and b, respectively. As x is name protected 

by OGuardedBy (A), Def. 0 entails that loc [itself h-q"]) £ C a and 

loc [itself^;"]) G £b, for l" = env(p'{l'))(x). As x is a field, by hy¬ 

pothesis the guard expression E may only contain the variables this and itself. 
As a consequence, loc ([£C o[t M S H-^][itseif^"]) = loc (MAs^] [itself^]) 

= loc ([A , C 6 [ th i SM . i /][ itse i fM .p/])- By Prop. □ this is not possible as two threads 
cannot lock the same location at the same time. 
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The requirement on the absence of aliasing is not necessary when working 
with a value-protection semantics. 

Theorem 4 (Value-protection semantics of OGuardedBy vs. data race pro¬ 
tection) . Let E be an expression in a program, and x be a variable or field that 
is value-protected by @GuardedBy(l?) . Let E contain no variable distinct from 
itself. Then no data race can occur at those locations bound to x, during any 
execution trace of the program. 


Proof. Again, the proof is by contradiction. Let (To, p o) > ■ • • — ^—4 (Tj, pf) 

be an arbitrary trace of our program. If a data race occurred at a location l 
bound to x in that trace, then that trace could evolve in at least two ways, 
both dereferencing l but in distinct threads, say a and b (Def. [FT]). Since x is 
value protected by @GuardedBy(T), both threads lock the value (ie., location) of 

E. Formally, by Def. IHl and fT7)l it follows that loc ([A'l^^itself n-z]) e &i an< ^ 
loc (P^J^itselfi-rZ]) e 4- Since itself is the only variable allowed in E, envi¬ 


ronments erf and a\ are irrelevant in these evaluations and loc ^ [T] 


loc 


([£]£■ 


itself i-ri] 


= loc 


(ra: 


’[itself h 


o-^itselft-rl]) 
Again, by Prop. CD this is impossi¬ 


ble, as two threads cannot lock the same location at the same time. 


B Properties of the Operational Semantics 

Let us provide a few properties showing the soundness of both the locking and 
unlocking mechanisms of our operational semantics. 

Two different threads never lock the same location: 

Proposition 2 (Locking vs. multithreading). Given an arbitrary execution 
trace 

(To, Id)} —>* (I'S'ilTi || • ■ ■ || \Sn\C n , p) 
then for any i,j £ { 1... n}, i ^ j entails CiC\ Cj =0. 

Proof. By induction on the length of the trace. 

When a thread starts its execution it does not hold any lock: 

Proposition 3 (Thread initialization vs. locking ). Let 

(T 0 , p 0 ) ->* (r^rlA || ... || \S n ]C n , p) A (r^rlA || ... || \S m \t m , p) 

be an arbitrary trace where Si = n.m[spawn E.p (); C] a :: S, for some k, to, E,p, C, a 
and S, then 

— &i = n'.p[B] a t, for appropriate k! , B and o' 

- <7 i+ i = K.m[C\ a :: S 

-4 = 0 
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” A+1 — A- 

Pi'oof. This is a direct conseuquence of the sematic rules [spawn], the only one 
which can be applied to perform the reduction step A>. 

When a thread terminates it does not keep locks on locations: 

Proposition 4 (Thread termination vs. locking ). Let 

(To, Mo) (AlA || • ■ ■ || \Sn\C n , fj,) 
be an arbitrary run where Si = e, , then A = 0- 
Pi'oof. By induction on the lenght of the reduction. 

A thread may not lock a location by mistake: 

Proposition 5 (Locking). Let 

(To, no) A (TA1A || ... || \Sn\L n , A A (TA1A || ... || \S m ]C m , fi) 
be an arbitrary run. Then (J™ =1 A Uj=i A > tf ani d 0 A tf 

— Si = K.m[monitor_enter(l);C'] a :: S, for some K,m,l,C',a and S 

— lock#(n(l)) = 0 and lock# (p,(l)) = 1 

— Ci = Ci W {/} 

— to = n and A = A f or ever y J G {1... n} \ {*}. 

Reentrant locks are allowed: only threads that already own the lock on an 
object can synchronize again on that object. 

Proposition 6 (Reentrant locking). Given an arbitrary run 

(To, mo) —t* (A1A II II A1A i m) 

where l £ Uj=i A'| for some l, and Si = K.m[monitor_enter(l);C']s :: S, for 
some i £ {1 ..n}, n, m, C, E, C', a and S. Then 

(A)A || ... || \s„]£ n , n) A (A 1A II... II \S n ] a , m) 

if and only if 

— I £ A 

— lock# (fi(l)) = lock# (m(0) + 1 

— to = n and A = A f or ever V 3 G {1 • ■ • n}. 

Proof. By case analysis on the rule applied to perform the reduction. Here the 
only rule which can be applied is [reeentrant-lock]. 

Locks on locations are never released by mistake: 
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Proposition 7 (Lock releasing). Let 

(T 0 , no) A || ... |j \Sn\L n , n) A {{§{]A || ... || rAl A, fi) 

be an arbitrary run. Then (J" =1 £j UyLi Lj, */ an ^ °A */ 

— 5) = n.m[monitor_exit (l); C}a :: S, for some n,m,l,C,a and S 

— Ci = Li w {i} 

— lock#(n(l)) = 1 and lock# (fi(l)) = 0 

— to = n and Cj = Cj for every jg{l.,.n} \ {*}. 

Proof. By case analysis on the rule applied to perform the reduction. Here the 
only possible rule is [release-lock]. 

Unlocking always happens after some locking: it may release the lock or not, 
depending on the number of previous lockings. 

Proposition 8 (Unlocking). Let 

(To, Mo) A (r-Sll A II • • ■ II \Sn\Cn , h) A (A1A || ... || \S m ] L m , ft) 

be an arbitrary run where Si = K.m[monitor_exit (l); C] a S, for some n, to, C , a 
and S, then 

— I & Ci 

— if lock# (m(0) > 1 then Li = Ci else Ci = Li l±J {1} 

— lock#(fi(l)) = lock# (m(0) — 1 

— to = n and Cj = Cj for every j £ {1... n} \ {*}. 


Proof. By case analysis on the rules applied to perforin the reduction. Here there 
are two possible rules: [decrease-lock] and [release-lo ck]. 



